home *** CD-ROM | disk | FTP | other *** search
- Path: tbj.dec.com!diamond
- From: diamond@tbj.dec.com (Norman Diamond)
- Newsgroups: comp.std.c
- Subject: Re: Bit-field sizes
- Date: 8 Mar 1996 03:04:38 GMT
- Organization: Digital Equipment Corporation Japan , Tokyo
- Message-ID: <4ho846$g2d@usenet.pa.dec.com>
- References: <nzRPxQ9ytZZA084yn@csn.net> <4hkgds$bbh@info1.sdrc.com> <uYgPxQ9ytt9W084yn@csn.net> <4hn3mg$c9v@info1.sdrc.com>
- Reply-To: diamond@tbj.dec.com (Norman Diamond)
- NNTP-Posting-Host: jit533.tbj.dec.com
-
- In article <4hn3mg$c9v@info1.sdrc.com>, larry.jones@sdrc.com (Larry Jones) writes:
- # (quoting the standard):
- # The expression that specifies the width of a bit-field shall be
- # an integral constant expression that nas nonnegative value that
- # shall not exceed the number of bits in an ordinary object of
- # compatible type.
- #
- >In article <uYgPxQ9ytt9W084yn@csn.net>, thads@csn.net (Thad Smith) writes:
- >> What does "ordinary object of compatible type" mean? Could that mean
- >> long? I now think that an implementation could allow specification of
- >> a number of bits greater than int, but less than or equal to bits in
- >> long. To access the value, the programmer casts the bit-field to long
- >> or unsigned long. The cast would preceed the integral promotion, I
- >> think, and allow access to the longer value.
-
- >An ordinary object (i.e., not a bit-field) with the same type as the
- >declared type of the bit-field which is required to be int, signed int,
- >or unsigned int. As Norm Diamond pointed out, that requirement is in
- >semantics, not constraints, so an implementation is free to add an
- >extension allowing other types (like long), and some do.
-
- Although I'm missing half the postings in this thread, everything sounds
- right so far.
-
- >Such implementations presumably extend the integral promotion rules in
- >the obvious fashion as well in order to eliminate the need for casts.
-
- They cannot. As Thad Smith's original posting pointed out, the standard
- prohibits this extension. And as Mr. Smith's later posting points out,
- as quoted above, a cast could do it. In order to permit implementations
- to provide this further extension without requiring casts, it would be
- necessary to revise the wording in ANSI Classic section 3.2.1.1, page 35
- lines 12 to 15. These lines (originally quoted my Mr. Smith) currently
- force the bit-field value into an int or unsigned int regardless.
- --
- << If this were the company's opinion, I would not be allowed to post it. >>
- "I paid money for this car, I pay taxes for vehicle registration and a driver's
- license, so I can drive in any lane I want, and no innocent victim gets to call
- the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
-